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Introduction 


Interpeer Project does R&D in “internet technology”; 
This talk is about the motivation; 


Led to a grant from ISOC foundation to explore solutions. 


ce Internet 


® Society 
° Foundation 


https://www.isocfoundation.org/ 
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Context 


We can take an easy path ora 
hard path. 


What happens when the easy 
path leads somewhere we don’t 
want to end up? 


Cable car & road at Tianmen mountain 
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Distribution 


Distribution is about resilience; 
routing around failures is the 
goal. 


Decentralization only provides 
this in the network at large, not 
for each centralized cluster. 


Client/server paradigm opposes 
distribution. 
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CENTRALIZED DECENTRALIZED DISTRIBUTED ' 
(A) (B) (C) 
FIG. | — Centralized, Decentralized and Distributed Networks 
Baran, P. (1964). On Distributed Communications, morandum RM-3420-PR. 
https://www.rand.org/content/dam/rand/pubs/research_memoranda/2006/RM3420.pdf 
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What is Web? REST? 


Fielding, Roy Thomas. Architectural Styles and the Design 

of Network-based Software Architectures. Doctoral dissertation, 
University of California, Irvine, 2000. 
https://www.ics.uci.edu/~fielding/pubs/dissertation/top.htm 


IS NOT HTTP (but inspired by work on HTTP/1.1) 
IS NOT software, framework, CRUD-style use of HTTP methods, etc. 
RESTful has little to do with REST. 
IS a decentratzed, scalable architecture. 
y —, 
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REST Overview 


Client Connector. CL} Client+Cache: 3 Server Connector (1) Server+Cache: CD 


Figure 5-10. Paocess View of a REST-based Aschitecture 

AL user agent is portrayed in the midst of three parallel interactions: a b, and c. The interactions wer 
not satisfied by the user agent's client connector cache, so each request has been souted to the resowme 
Ofigin accomling to the paoperties of each sesowme identifier and the configuration of the client 
connector. Request (a) has been sent to alocal paoxy, which in tum accesses acaching gateway found 
by DNS lookup, which forwaris the request on to be satisfied by an ofigin server whose intemal 
msoumes ae defined by an encapsulated object request banker amchitectum. Request (b) is sent directly 
to an ofigin server whichis able satisfy the request fromits own cache. Request (c) is sent to a proxy - =, 
that is capable of directly accessing WAIS, an infomation service that is separate from the Web 
amhitectum, and translating the WAIS sesponse into a fomrrat moognized by the genetic connector 
interface. Each cormponent is only aware of the interaction with their own client of server comnectoss; 
the overall paocess topology is an artifact of our view. 
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REST Overview 
REST provides an interface; clients do not need to know how a service is 
implemented. 


REST achieves this by defining that the data exchanged between client 
and service endpoint is a representation only. 


This is an elegant method for enabling a generic client. 
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Web Centralization 
HTTP is inherently client/server based; this pre-assigns roles to nodes 
and prevents nodes from “routing around failures”. 


AAA on the web is centralized (in a service); the endpoint decides, not 
the end user. This may also be a single point of failure for a service. 


RESTful may mistakenly map CRUD-style operations onto HTTP 
methods, but... 
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Web Centralization / CRUD 

PUT works as a generic CREATE; GET as a generic READ; DELETE as a 
generic DELETE; 

POST is terrible as a generic UPDATE: 


Representational means the client cannot a priori Know how to format 
a request. 


Requires the server to send appropriate code to the client (optional in 
REST). 


« Creates data + code silos in services. eatin 
en. 
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Web Centralization /Economic Incentives 


Service providers control access via AAA, control data via de-facto 
mandatory code for modification. 


Service providers can monetize this better the more data they gather, 


which means the incentives are stacked towards platformization 
(centralization). 


Surveillance capitalism is a natural fit for this. 


(heii 


W@ INTERPEER @IETF115 // DINRG // Web Centralization 


Web Centralization 


Centralization isn’t required by 
the web, but the incentives are 
Stacked towards It. 


How can we make the easy 
path also the path that pushes 
towards distribution? 


Cable car & road at Tianmen mountain 
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Distribution / AAA 


Move AAA from service endpoints to end users. 


¢ Distributed authentication: “solved” (the hard part, via public key 
cryptography). 
¢ Distributed authorization: capabilities, power of attorney (?) 


There is plenty of room for improvement, but it’s far from impossible. 
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Distribution / E2E data + operations 
Make data representation and operations an end-to-end problem 
(client-to-client)... 


E2EE takes out the service as interfering with the process; have data 
routers instead of services. 


CRUD style operations are no longer necessary at the transport; in fact, 
HTTP is no longer necessary. 


Natural fit for Information-Centric Networking (ICNRG). 
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THANK YOU 


E INTERPEER 


